Certain drawbacks exist in the way data is currently transformed, or marshaled, between data types. In existing systems, a user staffs with an existing Java type and asks the system to generate the XML schema that reflects the JAVA® type, and further to marshal the JAVA® data to the XML that was automatically generated. Most products that marshal XML run through a compiler, such as a JAVA® to WSDL compiler, in order to generate an XML schema. One drawback to such an approach is that only the scenario going from JAVA® to XML is addressed. Current tools are not particularly good at taking an existing XML schema and turning that entire schema into a convenient-to-use JAVA® type.
Another problem with current marshaling technologies appears when a user simply wishes to look at a small piece of XML data. That user may prefer to simply pass on the rest of the XML data without processing that data. Current marshaling technologies are not effective at simply passing on the remainder of the data. Typically, going from marshaling to unmarshaling is complicated, as not all semantics in XML can be easily captured in JAVA®. If a user brings in a message, changes a small portion of the message, and tries to resend the message as XML, portions other than that changed by the user will be different, such that a lot of other information may be lost. If the XML contains wildcard attributes or elements, for example, those wildcards will not be retained. Information about element order may also be lost or scrambled, which is a problem if the schema is sensitive to element order.